Filesystems for SSD

ля реализации уровня выше Tier 0 необходима какая-то ФС, так как все файловые
системы были спроектированы без учета "физической геометрии" твердотельных
накопитлей, то тут открыто большое пространство для творчества. Пока столбы
забили следующие системы: F2FS от самсунга и UBIFS. Остальное такое себе.

Все SSD используют трехуровневую систему страниц (так как и в RAM
контроллерах): Page, Block, Plane. Механизм трансляции этого в LBA называется
FTL (Flast Translation Layer), и если файловая система не aware про эту
адресацию, то вряд ли она будет эффективной. Состояния у страницы тоже
интересные: при апдейте создается отдельная страница (реврайтов страниц не
бывает), а старая маркируется как Stale, и когда набертся достаточное
количество Stale страниц в реалоцированом блоке — они "удаляются" и помечаются
как Erased. Это в принципе вся архитектура. Есть еще пяток простых
мнемонических правил:

1. Всегда работать с большимы блоками (батчинг, накапливание сообщений в блобы).
2. Разделять холодные и горячие данные.
3. Много мелких запросов паралелить по ядрам
4. Дата локалити (имеет смысл в основном для ФС-писателей)
5. Разделять врайтеров и ридеров во времени

Свойство условно-хорошего слоя FS со стороны хоста зеркалировать эту FTL
адресацию, поэтому в сущности UBIFS повторяет алгоритм FTL, с поправкой на
требования хоста. Вопрос синхронизации буферов на концах соединения тоже
интересный. Ясно что для ACHI и NVMe должны быть разные параметры у алгоритма,
так как в NVMe 64K глубина очереди, а в ACHI всего 32.

А пока для режима Tier 0 я вышел на стабильные 340MB/s из теоретических 700MB/s
(как говрит Андрей, радиус кривизны рук у меня 48%), еще попробую одну идейку,
а потом буду на С++ переписывать наверное. Свой ивент рекордер я переписал,
убрал все OTP нахуй, сделал идиоматический эрланг, который можно теперь
переписывать на другие языки. Кто хочет померятся хуйями на Node, CLR, JVM, Lua
дайте знать, я тогда составлю документ "условия соревнований". Вся проблема —
накопить быстро достаточно большой бинарь из миллиарда маленьких сообщений
чтобы флашнуть его на диск. Код на современных языках не выходит за рамки
100-200 строк. Подойдут и фьючеры и акторы. Все языки пишут одинаково быстро
через File:Write[append], так что тут проблем тоже нет.

У моего вариативного алгоритма всего два параметра: msg_size и block_size.
Первый означает по сколько склеивать сообщений на клиенте еще до отправки на
сервер (чтобы разгрузить копирование в языке или виртуальной машине), а второй
по сколько пихать в SSD, чтобы снизить нагрузку на контроллер. Вариатор по этим
двум осям ищет максимум.

_______________
[1]. http://www.linux-mtd.infradead.org/doc/ubidesign/ubidesign.pdf
[2]. https://www.usenix.org/system/files/conference/fast15/fast15-paper-lee.pdf